In some networks, such as Multiprotocol Label Switching (MPLS) networks, a Traffic Engineering (TE) Label Switched Path (LSP) can be established using a Resource Reservation Protocol-TE (RSVP-TE) for a given path. A path can be provided by a Path Computation Client (PCC) and/or a Path Computation Element (PCE). For example, the PCC may request a path or route from the PCE, which computes the path and forwards the computed path information back to the PCC. The path can be a Point-to-Multipoint (P2MP) path from a source node to a plurality of destination nodes.
The Internet Engineering Task Force (IETF) request for comment (RFC) 4090 entitled “Fast Reroute Extensions to RSVP-TE for LSP Tunnels,” which is published in http://ietfreportisoc.org/rfc/rfc4090.txt and incorporated herein by reference, describes two methods to backup point-to-point (P2P) LSP tunnels or paths at local repair points. The local repair points may comprise a plurality of internal nodes between an ingress node and an egress node along the path. The first method is a one-to-one backup method, where a detour backup P2P LSP for each protected P2P LSP is created at each potential point of local repair. The second method is a facility bypass backup protection method, where a bypass backup P2P LSP tunnel is created using MPLS label stacking to protect a potential failure point for a set of P2P LSP tunnels. The bypass backup tunnel can protect a set of P2P LSPs that have similar backup constraints.
The IETF RFC 4875 entitled “Extensions to RSVP-TE for Point-to-Multipoint TE Label Switched Paths (LSPs)”, which is published in http://ietfreportisoc.org/rfc/rfc4875.txt and incorporated herein by reference, describes how to use the one-to-one backup method and facility bypass backup method to protect a link or internal node failure on the path of a P2MP LSP. However, there is no mention of protecting locally an ingress or egress node failure in a protected P2MP LSP.